@tom95 This does neither fix nor solve the problem. Actually this breaks the handling of i.e. structs, vim wont really resolve them anymore afterwards. And what I also noticed is that, since some of the "latest" updates of deoplete it seems like this whole module operators far less good than before. Before it resolved functions from a different header just fine. Now it does not anymore, only when I type it out myself as a function and press backspace after that it will resolv the clang completion correctly. I assume something in deoplete just lately changed which altered the behavior hugely.

When I created this patch it solved all problems I encountered. Trying it right now with the newest deoplete, I only receive a lot of errors, both with and without my patch, so I'd guess some API change in deoplete is causing trouble.

probably, would also be my guess, before I've updated today, everything worked even without your patch though. So it is probably entirely due to the API. Unfortunately i don't know which version I used before :/

@tweekmonster Do you have something in work concerning this topic?

Reprodocued.

It should be removed.

I don't know the implementation though.

You can configure it manually.

call deoplete#custom#source('clang2', 'min_pattern_length', 2)

@tweekmonster Ping.

@Shougo I will test it in SpaceVim，and will fix it.

@Shougo I was trying to take a look, but I can't seem to get logging to work.

Also, the reason for having the min length set to 0 was because it relied on the auto_complete_delay to get the "min length" from human behavior instead of an arbitrary fixed minimum. That way typing whatever-> and pausing would actually give you results instead of needing to type two more characters. Don't know about you, but I often don't know what I'm looking for and rely on completions to peek into struct membership.

It looks like the default delay was lowered from 150 to 50. Try raising it to 150. In my experience, 250ms is where it starts to annoyingly noticeable.

50ms is pretty low considering that in most fast apps, there's a ~20ms round trip from hardware key press to software key processing. In terminal nvim, the delay could be greater since there's a Terminal emulator that processes the keystrokes before forwarding it to nvim, even more so if tmux and/or ssh is involved. nvim GUIs could have noticeable delays as well since nvim is controlled via RPC.

In any case, these completions could benefit from maintaining a stale cache to get completions out faster (sort of like deoplete-jedi's stale cache).

@Shougo I was trying to take a look, but I can't seem to get logging to work.

It is deoplete's bug. It is already fixed in master.

because it relied on the auto_complete_delay to get the "min length" from human behavior instead of an arbitrary fixed minimum.

Why does not use input_pattern feature?

Why does not use input_pattern feature?

It was deferred to get_complete_position() because pattern has to be slightly different for ObjC and C++. I can't remember the exact reason I had, but it was easier to handle that way.